§1.1 Field of the Invention
The present invention concerns the establishment, use, and/or maintenance of label switched paths, particularly when a protocol used to establish, maintain, and/or tear down such paths, or when a node through which the path passes, is restarting. More specifically, the present invention minimizes the effects of protocol or node control component restart(s) on the flow of data (such as a flow of packets) over the label switched path.
§1.2 Description of Related Art
The description of art in this section is not, and should not be interpreted to be, an admission that such art is prior art to the present invention. Although one skilled in the art will be familiar with networking, circuit switching, packet switching, label switched paths, and protocols such as BGP, RSVP, MPLS, and LDP, each is briefly introduced below for the convenience of the less experienced reader. More specifically, circuit switched and packet switched networks are introduced in §1.2.1. The need for label switched paths, as well as their operation and establishment, are introduced in §§1.2.2-1.2.4 below. Finally, “failures” in a label switched path, as well as typical failure responses, are introduced in §1.2.5 below.
§1.2.1 Circuit Switched Networks and Packet Switched Networks
Circuit switched networks establish a connection between hosts (parties to a communication) for the duration of their communication (“call”). The public switched telephone network (“PSTN”) is an example of a circuit switched network, where parties to a call are provided with a connection for the duration of the call. Unfortunately, many communications applications, circuit switched networks use network resources inefficiently. Consider for example, the communications of short, infrequent “bursts” of data between hosts. Providing a connection for the duration of a call between such hosts simply wastes communications resources when no data is being transferred. Such inefficiencies have lead to packet switched networks.
Packet switched networks, forward addressed data (referred to as “packets” in the specification below without loss of generality), typically on a best efforts basis, from a source to a destination. Many large packet switched networks are made up of interconnected nodes (referred to as “routers” in the specification below without loss of generality). The routers may be geographically distributed throughout a region and connected by links (e.g., optical fiber, copper cable, wireless transmission channels, etc.). In such a network, each router typically interfaces with (e.g., terminates) multiple links.
Packets traverse the network by being forwarded from router to router until they reach their destinations (as typically specified by so-called layer-3 addresses in the packet headers). Unlike switches, which establish a connection for the duration of a “call” or “session” to send data received on a given input port out on a given output port, routers determine the destination addresses of received packets and, based on these destination addresses, determine, in each case, the appropriate link on which to send them. Routers may use protocols to discover the topology of the network, and algorithms to determine the most efficient ways to forward packets towards a particular destination address(es). Since the network topology can change, packets destined for the same address may be routed differently. Such packets can even arrive out of sequence.
§1.2.2 The Need for Label Switched Paths
In some cases, it may be considered desirable to establish a fixed path through at least a part of a packet switched network for at least some packets. More specifically, merely using known routing protocols (e.g., shortest path algorithms) to determine paths is becoming unacceptable in light of the ever-increasing volume of Internet traffic and the mission-critical nature of some internet applications. Such known routing protocols can actually contribute to network congestion if they do not account for bandwidth availability and traffic characteristics when constructing routing (and forwarding) tables.
Traffic engineering permits network administrators to map traffic flows onto an existing physical topology. In this way, network administrators can move traffic flows away from congested shortest paths to a less congested path, or paths. Alternatively, paths can be determined autonomously, even on demand. Label-switching can be used to establish a fixed path from a head-end node (e.g., an ingress router) to a tail-end node (e.g., an egress router). The fixed path may be determined using known protocols such as RSVP and LDP. Once a path is determined, each router in the path may be configured (manually, or via some signaling mechanism) to forward packets to a peer (e.g., a “downstream” or “upstream” neighbor) router in the path. Routers in the path determine that a given set of packets (e.g., a flow) are to be sent over the fixed path (as opposed to being routed individually) based on unique labels added to the packets. Analogs of label switched paths can also be used in circuit switched networks. For example, generalized MPLS (GMPLS) can be used in circuit switched networks having switches, optical cross-connects, SONET/SDH cross-connects, etc. In MPLS a label is provided, explicitly, in the data. However, in GMPLS, a label to be associated with data can be provided explicitly, in the data, or can be inferred from something external to the data, such as a port on which the data was received, or a time slot in which the data was carried, for example.
§1.2.3 Operations of Label Switched Paths
In one exemplary embodiment, the virtual link generated is a label-switched path (“LSP”). More specifically, recognizing that the operation of forwarding a packet, based on address information, to a next hop can be thought of as two steps—partitioning the entire set of possible packets or, other data to be communicated (referred to as “packets” in the specification without loss of generality), into a set of forwarding equivalence classes (“FECs”), and mapping each FEC to a next hop. As far as the forwarding decision is concerned, different packets which get mapped to the same FEC are indistinguishable. In one technique concerning label switched paths, dubbed “multiprotocol label switching” (or “MPLS”), a particular packet is assigned to a particular FEC just once, as the packet enters the label-switched domain (part of the) network. The FEC to which the packet is assigned is encoded as a label, typically a short, fixed length value. Thus, at subsequent nodes, no further header analysis need be done—all subsequent forwarding over the label-switched domain is driven by the labels.
FIG. 1 illustrates a label-switched path 110 across a network. Notice that label-switched paths 110 are (generally) simplex—traffic flows in one direction from a head-end label-switching router (or “LSR”) 120 at an ingress edge to a tail-end label-switching router 130 at an egress edge. Generally, duplex traffic requires two label-switched paths—one for each direction. However, some protocols support bi-directional label-switched paths. Notice that a label-switched path 110 is defined by the concatenation of one or more label-switched hops, allowing a packet to be forwarded from one label-switching router (LSR) to another across the MPLS domain 110.
Recall that a label may be a short, fixed-length value carried in the packet's header (or may be inferred from something external to the data such as the port number on which the data was received (e.g., in the case of optical cross-connects), or the time slot in which the data was carried (e.g., in the case of SONET/SDH cross connects) of addressed data or of a cell) to identify a forwarding equivalence class (or “FEC”). Recall further that a FEC is a set of packets (or more generally data) that are forwarded over the same path through a network, sometimes even if their ultimate destinations are different. At the ingress edge of the network, each packet is assigned an initial label (e.g., based on all or a part of its layer 3 destination address). More specifically, referring to the example illustrated in FIG. 2, an ingress label-switching router 510 interprets the destination address 220 of an unlabeled packet, performs a longest-match routing table lookup, maps the packet to an FEC, assigns a label 230 to the packet and forwards it to the next hop in the label-switched path.
In the MPLS domain, the label-switching routers (LSRs) 220 ignore the packet's network layer header and simply forward the packet using label-swapping. More specifically, when a labeled packet arrives at a label-switching router (LSR), the input port number and the label are used as lookup keys into an MPLS forwarding table. (See, e.g., FIG. 5. Note that column 550 of FIG. 5 is a novel aspect of the present invention, and is therefore not provided in conventional tables.) When a match is found, the forwarding component retrieves the associated outgoing label, the outgoing interface (or port), and the next hop address from the forwarding table. The incoming label is replaced with the outgoing label and the packet is directed to the outgoing interface for transmission to the next hop in the label-switched path. FIG. 2 illustrates such label-switching by label-switching routers (LSRs) 220a and 220b. 
When the labeled packet arrives at the egress label-switching router, if the next hop is not a label-switching router, the egress label-switching router discards (“pops”) the label and forwards the packet using conventional longest-match IP forwarding. FIG. 2 illustrates such label discarding and IP forwarding by egress label-switching router 240.
§1.2.4 Establishing Label Switched Paths
In the example illustrated with reference to FIG. 2, each label-switching router had appropriate forwarding labels. However, these labels must be provided to the label-switching routers in some way.
There are four basic types of LSPs—static LSPs, label distribution protocol (“LDP”) signaled LSPs, border gateway protocol (“BGP”) signed LSPs and resource reservation protocol (“RSVP”) signaled LSPs. Although each type of LSP is known to those skilled in the art, each is introduced below for the reader's convenience.
With static LSPs, labels are manually assigned on all routers involved in the path. No signaling operations by the nodes are needed.
With LDP signaled LSPs, routers establish label-switched paths (LSPs) through a network by mapping network-layer routing information directly to label switched paths. LDP operates in a hop-by-hop fashion as opposed to RSVP's end-to-end fashion. More specifically, LDP associates a set of destinations (route prefixes and router addresses) with each data link LSP. This set of destinations is called the Forwarding Equivalence Class (“FEC”). These destinations all share a common data link layer-switched path egress and a common unicast routing path. Each router chooses the label advertised by the next hop for the FEC and splices it to the label it advertises to all other routers. This forms a tree of LSPs that converge on the egress router.
With RSVP signaled LSPs, an ingress (i.e., head-end) router is configured. The head-end router uses (e.g., explicit path and/or path constraint) configuration information to determine the path. The egress (i.e., tail-end) and transit routers accept signaling information from the ingress (i.e., head-end) router. The routers of the LSP set up and maintain the LSP cooperatively. Any errors encountered when establishing an LSP are reported back to the ingress (i.e., head-end) router.
Using exterior gateway protocols, such as BGP-4, label information can be communicated between so-called “autonomous systems” (or “AS”) and even within an AS. (See, e.g., “Request for Comments: 3107”, by Y. Rekhter and E. Rosen, (Internet Engineering Task Force, May 2001). This RFC is incorporated herein by reference.) As is well understood in the art, an autonomous system is a network (e.g., composed of a set of routers) under the control of a single administrative entity, or within a given routing domain.
FIG. 3 illustrates the binding of a label to a forwarding equivalency class (“FEC”) and the communication of such label binding information among peer nodes. In this example, suppose FEC “j” defines all packets that are destined for, or want to pass through, IP address 219.1.1.1. Notice that each of the nodes may be thought of as including a control component 330 and a forwarding component 310.
At the edge of the label-switched path 390, a node 240′ assigns a label “2” to FEC j. This association is stored as label information 340c, as indicated by 350. Furthermore, this association is communicated to an upstream node (also referred to as a “peer” or “neighbor” node) 220b′ as indicated by communication 352.
Node 220b′ assigns its own label “9” to FEC j. This binding is similarly stored as label information 340b. Further, using the FEC j, the node 220b′ binds its label “9” to the received label “2”, and stores them as an IN label 322b and an OUT label 324b forwarding information 320b, as indicated by 354. Furthermore, its 220b′ association is communicated to an upstream node (also referred to as a “peer” or “neighbor” node) 220a′ as indicated by communication 356.
Node 220a′ assigns its own label “5” to FEC j. This binding is similarly stored as label information 340a. Further, using the FEC j, the node 220a′ binds its label “5” to the received label “9”, and stores them as an IN label 322a and an OUT label 324a forwarding information 320ab, as indicated by 358. Furthermore, its 220a′ association is communicated to an upstream node (not shown) as indicated by communication 359.
This process of using the FEC to bind a label with a received label, as well as communicating a label to a peer or neighbor node, results in the establishment of a label-switched path, such as that illustrated in FIG. 2.
§1.2.5 Responding to “Failures” in a Label Switched Path
In the following, neighboring routers in a label switched paths may be referred to as “peers” or “neighbors”. If the interface of a router, the link to its neighbor, or an associated interface of the neighbor goes down (i.e., doesn't function), the router can reroute packets, for example using methods such as those described in U.S. patent application Ser. No. 09/354,640, entitled “METHOD AND APPARATUS FOR FAST REROUTE IN A CONNECTION-ORIENTED NETWORK,” filed on Jul. 15, 1999. This application is incorporated herein by reference.
Sometimes, a control component part of a router in a label switch path, or a part of the control component, will restart. Such a restart may be caused, for example, by upgrading software and/or hardware of the control components, the control component receiving unexpected (path signaling) messages from its neighbor(s), the control component failing to receive expected (path signaling) messages from its neighbor(s), etc. Whatever the cause of the restart, the restarting node will typically purge its forwarding information (Recall, e.g., 320 of FIG. 3.), and will typically lose label information (Recall, e.g., 330 of FIG. 3.). For example, referring back to FIG. 3, if the control component 330b of node 220b′ restarts, it will purge stored forwarding information 320b and will lose label information 340b. Furthermore, this restart affects other routers in the label-switched paths. For example, when nodes 220a′ and 240′ learn that the node 220b′ is restarting, they will purge forwarding information 320a/320c related to the path through node 220b′. 
This scenario has at least two disadvantages. First, as shown in FIG. 3, some routers have forwarding components that can, at least theoretically, continue forwarding packets even when their control component, or a part thereof, is restarting. (For example, routers from Juniper Networks Inc. of Sunnyvale, Calif. have a packet forwarding engine and a routing engine.) Second, after the restart is complete, the node and its neighbors need to repopulate their forwarding information. During this period, the label switched path(s) through node 220b′ cannot be used.
It is desired to minimize the effects of such restart(s) on the flow of packets over the label switched path.